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A Different Way to Think About TAPR 


By John Ackermann, N8UR, n8ur@tapr.org 


Something clicked for me while I was behind 
the counter at the TAPR Hamvention booth, 
watching the intense discussion going on around 
the Gnuradio/USRP part 
of the table. 


For those of you who 
don’t know, Gnuradio is 
a software project led by 
Eric Blossom, K7GNU, 
and Matt Ettus, N2MJI. 


It’s aimed at creating 


the building blocks for software-defined radio 
running on a PC. Using the Gnuradio tools, 
you can write the code for a complete receiver in 
perhaps 100 lines of code. 


The USRP is a hardware project developed 
and sold by Matt. It’s an external board that 
talks to the PC via USB and contains high- 
speed analog-to-digital and digital-to-analog 
converters, as well as glue logic. It has room for 
up to four daughterboards that provide the RF 
front-end. The USRP can be the foundation of 
a complete radio system and was designed to 
work with Gnuradio. 


As I saw the interest that Matt and Eric had 
created, I thought back to a couple of years 
ago when Gerald Youngblood, now K5SDR, 
but then AC5OG, had his very first SDR-1000 
software-defined radio boards in that same spot 
at our booth. 
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And I thought back even further, more than 
ten years, to when Bob Bruninga, WB4APR, 
and the Sproul brothers, Mark, KB2ICI, and 
Keith, WU2Z, were showing off their fledging 
APRS software at an earlier version of the 


TAPR booth. 


The lightbulb that went on for me is that 
while TAPR has had more than a few products 
of its own to be proud of, perhaps our biggest 
impact since the TNC-2 has been through our 
role as a technology incubator. Even though 
the APRS software, the SDR-1000, Gnuradio, 
and the USRP weren’t TAPR products, we were 
there to support those innovators and watch as 
they went on to make a big impact in the ham 
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radio world and beyond. 


Now, taking that role doesn’t put money in 
our bank account. But I think it is absolutely 
the right thing to do and I think everyone 
involved with TAPR, whether as officer, 
volunteer, or member, should be very proud 
of the role we’ve taken to support of new 
technology, whether it’s sold by us or by 
someone else. 


The Worldwide Workbench 


I wrote previously about how Mario, 
DL5MLO/KC5WHE, developed a Linux 
version of the TAPR/Ten-Tec Vector Network 
Analyzer software without ever having seen 
the hardware. It’s an amazing story of how the 
Internet has enabled hams to work together 
across continents the way we used to work 
together across town. 


I'd like to expand on this idea of long-distance 
collaboration; it doesn’t have to be as extreme 
as Mario’s case to be effective. 


Without many of us realizing it, the Internet 
has really changed the way we can work on 
technology projects. In the old days, your local 
radio club was the main source of feedback and 
inspiration. If you were lucky, you might run 
into someone on the air who knew about that 
roadblock that was stumping you, but finding 
specialized knowledge was like searching for 
a needle in a haystack. I remember writing to 


the ARRL technical service for simple circuit 
advice, simply because I couldn’t find the 
answer locally (and they were very helpful). 


Today, search engines like Google and the 
widespread use of specialized mailing lists 
have created an incredible ability to dig 
for information. I’ve seen a couple of great 
examples in my own work recently. 


I’m working on my first TAPR project (more 
on that in the next PSR!), and as we usually 
do, we set up a mailing list at www.tapr.org 
for beta testers and others interested in the 
project. I was able to use that list to get input 
on what features people wanted in this product, 
and as a result, I was able to make significant 
design changes to meet those needs. That may 
not seem too sexy ~ some people call it "market 
research" ~ but it was sure a lot easier than 
standing out on the corner with a survey form! 


After finalizing the circuit, I was able to send 
the schematic and PCB layout files to the group 
and got excellent feedback from people much 
more knowledgeable about RF design than I. 

In fact, I completely redesigned the board as a 
result of that input and it’s now a much better 
board than my first attempt. My on-line helpers 
ranged from being on the other side of town, to 
the other side of the country, to the other side 
of the Atlantic. 
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In another example of long-distance 
collaboration, TAPR VP Steve Bible, N7HPR, 
has been working with Luis Cupido, CTIDMK, 
to do a TAPR version of Luis’ "Reflock II" 
universal frequency control. I don’t think Steve 
and Luis have ever met in person or even talked 
on the phone, but they worked closely as a team 
to create a great product, using e-mail to send 
schematics, spectrum analyzer captures, and 
other data back and forth, as well as just talk 
things through. 


We've been using e-mail and the web so long 
now that most of us no longer see how they 
have changed things. They make it possible 
for us to have a "Worldwide Workbench" that 
multiplies our individual capabilities. If you 
have a project you'd like to work on, but don’t 
have quite enough background or information 
to pull it off, don’t give up ~ use the web, scout 
for mailing lists or newsgroups where you might 
find help. You'll be amazed at the resources 
that are there for the taking. 


It's DCC Time! 


We’re just about a month away from this 
year’s Digital Communications Conference, to 
be held in Santa Ana, CA, September 23-25. 
Registration and hotel rates go up after August 
31, so make your plans now. See you there! 


HEF 
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Election of TAPR Board of Directors 


The following three TAPR members have agreed to run for the three available positions on the Steven Bible, N7HPR 
TAPR Board of Directors: Steve Bible, N7HPR, Stan Horzepa, WAILOU, and Darryl Smith, 
VK2DTS. Board members serve three-year terms. 


Steve has been involved 
with amateur digital red 6 
This year, there are three ways to vote: communications since 1985. > 
¢ Online at www.tapr.org/ballot He began work with TAPR 4 

in 1995 serving as board 

member and presently serves Ali 

as vice president. Steve | 
Mail-in ballots go to TAPR, PO Box 852754, Richardson, TX 75085-2754 enjoys the research and 
Online voting begins on September 1. The deadline for all balloting is September 14. development side of the Amateur Radio hobby. 
He has been involved in the development of 
several TAPR kits helping bring them to the 
amateur population. The TAC-2, DGPSIB, 
2005 Ballot for TAPR Board of Directors PICE, T-238, to name only a few. Steve has 
lectured extensively at clubs and hamfests 


on spread spectrum and software radio 
helping amateurs begin experimentation and 


¢ Mail in a printed copy of the ballot from www.tapr.org/ballot 


¢ Mail in the ballot printed below. 


Deadline for all balloting is September 14. 


Vote for three (maximum): 


[| Steve Bible, N7HPR exploration of these technologies. 
[ | Stan Horzepa, WA1LOU Steve resides in Chandler, AZ and works as a 
[ | Darryl Smith, VK2DTS Principal Applications Engineer for Microchip 
LL Write-in candidate: nee “a a 
[| Write-in candidate: an horzepa, : 
[| Write-in candidate: Born 1951, Waterbury, 
CT 
Your TAPR membership number*; — BA, University of 


Connecticut (1973); JD, 


*If you don’t know your membership number, contact the TAPR office via www.tapr.org/inforequest, phone Western New Eng land 
972-67-TAPR (8277), fax 972-671-8716, or mail TAPR, PO Box 852754, Richardson, TX 75085-2754. Office College (1977) 
Hours: (US Central Time zone) 0900-1700 Monday - Friday. 


Last four digits of your telephone number: 
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Senior Technical Writer at CCOR, Inc. 


Resides on Compounce Mountain, Wolcott, 
CT 

Married with child plus 5 cats, 2 dogs, and 1 
fish 

Amateur Extra Class, first licensed in 1969 
(WNILOU) 

TAPR member since 1985 

TAPR Packet Status Register editor since 2002 

TAPR SIG administrator of APRSNEWS, 
APRSSAT, APRSSIG, APRSSPEC, HTAPRS 

APRS QSY Committee, 1997-98 

APRS Working Group, secretary 

ARRL Life Member 

ARRL headquarters staff, 1977-1979 

OST contributing editor, 1979 to present 
(FM/RPT, On Line, Packet Perspective, Digital 
Dimension), ARRLWeb contributing editor, 
2000 to present (Surfin’) 

Author: Your Gateway to Packet Radio (ARRL, 
1987, 1989), Practical Packet Radio (ARRL 
1995), Getting on Track with APRS (ARRL 
1996), APRS: Tracks, Maps and Mobiles (ARRL 
1999), APRS: Moving Hams on Radio and the 
Internet (ARRL, 2004), The ARRL Operating 
Manual (ARRL, 1980, 1985, 1987, 1991, 1995, 


1997, 2000) 
E-mail wallou@tapr.org 
Web site http://homepage.mac.com/stanzapple/ 
Darryl Smith, VA2TDS 
Vk2tds@tapr.org 


http://www.radioc-active. 
net.au 


Darryl@radio-active.net. 
au 


PO Box 169 
Inglenburn NSW 2565 
Australia 

+61 412 929 634 


Darryl Smith is a 35-year-old Electrical 
Engineer, based in Sydney, Australia. He has 
been licensed asVK2TDS since 1993, when he 
gained his license in order to experiment with 
packet radio. For his Electrical Engineering 
thesis, he investigated spread spectrum data 
communications - with the work now available 


via the TAPR WWW site. 


Professionally Darryl has been working 
in the electricity generation industry for 12 
years, doing a cadetship with the state owned 
electricity generator. Since graduation he has 
worked as an electrical plant owner in a large 
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coal power station, and more recently working 
in the IT group managing drawings within the 
organization. 


Darryl owns and operates Radioactive 
Networks, an engineering consulting company 
specializing in mobile data and GPS tracking 
technology. 


Darryl has been a member of TAPR since 
1997. He presented a paper in the 1997 DCC, 
and has written a number of papers since then. 
Darryl has been an active member of the APRS 
community for a number of years and has been 
heavily involved in setting up the Australian 


and New Zealand APRS networks. 
HHH 
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Evolution of TAPR/TEN-TEC RF Vector Network Analyzer 


By Tom Salvetti, KC3NF, Tsalvetti@cs.com 


It all started with an e-mail to TAPR from 
Tom McDermott, N5EG, in the fall of 2003. 
Tom and a friend, Karl Ireland, conceived 
and built an incredibly unique piece of test 
equipment, humbly dubbed the “Vector 
Network Analyzer” or “VNA” for short. 


Let’s put in perspective what this idea 
represents to Amateur Radio 
experimenters. Most of us can only 
dream of owning a conventional bench- 
top network analyzer. Even a used 
model typically sells for $5000 and up. 
Tom and Karl designed a standalone 
board to do the actual measurements 
and then created software that runs on 
your personal computer to replace the 
rest of the computational horsepower 
and displays of a conventional network 
analyzer. Now we’ve got something we 
hams can afford for our own workshop! 
More on that to come; let’s get back to the 
history. 

Revision | was already up and running when 
Tom contacted TAPR. As has been TAPR’s 
tradition with other technical innovations, 
Tom hoped they would be interested in 
“kitting” the VNA to make it more readily 


available to hams. It didn’t take long for 
TAPR to join forces with Tom. 


Additional development work followed, 
resulting in Revision 2. Then the decision 
was made that TAPR fund the building of ten 
beta units. The call went out and ten intrepid 
experimenters stepped up to the task. 


RECEIve 


There was one particular mechanical hurdle 
to overcome. The VNA circuit design was 
state-of-the-art and included the use of eight 
fine pitch SMD ICs. Soldering surface mount 
ICs is challenging enough, but hand soldering 
fine pitch parts moves into a world of its own! 
Steve Bible, N7HPR, stepped forward to solve 
this one and installed the fine pitch parts on 


all ten boards. The beta team then assembled 
the balance of their individual boards laying 
down the remaining 130 components, 
connectors, etc. Certainly noteworthy in 

the kit environment and to the credit of 
everyone involved, all ten were brought to life 
successfully. 


Coincidentally, Tom had submitted 
an article to QEX for consideration 
about the same time as he made the 
initial contacts with TAPR. QEX 
accepted and published in the July/ 
August 2004 issue. The VNA article 
was so well received that Tom and Karl 
were awarded the 2004 Doug DeMaw, 
WHIEB, Technical Excellence Award for 
outstanding technical article in QST or 


QEX. 


As beta testing moved forward, 
feedback, and suggestions started 
to flow. All the while, Tom continued 
development of the PC software. A number 
of hardware improvements were identified 
and incorporated, with the VNA now called 
Revision 3. 


It was time for the May 2004 Dayton 
Hamvention. The VNA was shown and 
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demonstrated. Everyone involved realized the 
challenge of making a kit readily available 

to the rest of the hobby. Steve had labored 
through mounting the fine pitch parts on ten 
boards, but no one expected him to scale up 
to larger quantities. Then Steve came up with 
an idea. How about TAPR partnering with a 
manufacturer that would provide factory built 
models? While still 
there at Dayton, 
Steve approached 
Gary Barbour, 
AC4DL, Vice 
President of TEN- 
TEC. 


Discussions 


RECEIVE 


Te 


POWER 


: (-)-<@ (+) 2 
began in earnest : 
between TAPR 

and TEN-TEC and 


an agreement was 


5VDC 2AMPS 


reached soon after. Members will recognize 
that TAPR has licensed product designs to 
other firms a number of times throughout its 
history, but there is one aspect of the VNA 
program that breaks new ground. The VNA 
will be co-branded TAPR and TEN-TEC 
providing TAPR with continuing recognition 
of their role in the project. TAPR will also 
receive royalties on the sale of every unit. This 
helps support TAPR’s fundamental mission 


: Oo Axc=—@ 


TEN-TEC RF VECTOR NETWORK ANALYZER 


EXT REF 


ae 


to provide leadership and resources to radio 
amateurs for the purpose of advancing the art 
of radio. 


TEN-TEC recently finished building a 
small production run. These units are now 
out in the hands of beta testers. Model 6000 
TAPR/TEN-TEC RF Vector Network Analyzer 
should be available for shipment to customers 
in September. 
Designed for testing 
up to 100 MHz, the 

unit connects to 

i your PC via USB 
and the software 
runs on Windows- 
based systems. 


TRANSMIT 


COMPUTER 


yy 


Linux fans will be 
pleased to learn 


TEN-TEC, INC. 
SEVIERVILLE, TN 
MADE IN USA 


that Mario Lorenz, 
DL5MLO, has 
already developed a Linux port and tested it 
extensively. 


The VNA sells for $655, which includes a 
set of testing and calibration accessories: 1 
and 3-meter cables, 10 and 30-db attenuators, 
50-ohm load, shorted connector, and barrel 
connector. Interested hams are encouraged to 
visit the TAPR or TEN-TEC web sites to learn 


more. 
HEF 
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Wanted: Unpopulated DSP-93 PC Board (The 
DSP Engine Board) 


We have a couple of DSP-93s here in OZland and 
one of them will simply not work. All our attempts 
to diagnose the problem have been unsuccessful 
and we now believe that moving all the components 
to a new unpopulated board is the only way out. 
For this reason, we seek a bare DSP Engine board. 
If you have one, please contact me. A partly or fully 
populated board will also be of interest. 


Best 73 de Bent, OZ6BL, e-mail oz6bl@amsat.org 
HHH 
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Product Review: Garmin GPS18 PC GPS Receiver 


By Guy Story, KC5GOI, kc5goi@kc5goi.net 


This May I was given an opportunity to test out a new 
Garmin GPS receiver called the GPS18PC. It is a new 
version of what has been referred to as Garmin’s Hockey 
Puck receivers. The older Garmin 30 was one of their 
first. To demonstrate how technology has changed, the 
Garmin GPS 30 was an eightchannel receiver but was 
serial in how it track satellites instead of parallel, as are most 
receivers today. At the time that was the technology and 
itworked ok. Acquisition times were slower and receiver 
sensitivity was lacking in comparison to today. The GPS 18 
isa 12.channel, parallel receiver. This allows for monitoring 
of multiple GPS satellites at a single time. The receiver 
sensitivity improvements allow a receiver to achieve a lock 


much quicker. 


The Garmin GPS18 is actually a family of receivers. 
There are the I8PC, I8USB and the 18 LVC (includes the 
LVGC5M and the 18-5Hz). First, a word of caution. The 
18USB is just that, a USB device. It only sends out Garmin 
proprietary sentences. I am not aware of any of the APRS 
programs that can use the Garmin sentences in the same 
fashion as the NMEA sentences. This is great if you are 
using mapping software standalone but not for APRS. 


First the pluses and some differences between the rest 
of the receivers. I have tested the 18 PC version and was 
very impressed, The 18 PC has an adaptor to plug into a 
cigarette lighter adapter in your vehicle and a female db9 
to connect to the PC. The cigarette lighter adapter has a 


voltage regulator in it and measures 11.5 centimeters in 
length. It does give you the pilot light LED to let you know 
itis on. The data and power connections are each 80 

cm in length. The overall length is 2.1 meters. The actual 
receiver section is 6.5 cm in diameter. A 1 PPS output is 


not provided. The receiver pulls 50mA at 13.8 VDC. 


The GPS 18 LVC family has a single cable assembly 
coming from the receiver. First word of caution is that 
there is no voltage regulation. You will need to provide 
regulated 5 VDC. The I8LVC has a 3-meter cable; the 
LVC5m and 185Hz have 5meter long cables. The 
receivers pull 60 mA @ 5.0 VDC. I personally find these 
attributes to be an advantage. The unfinished pigtail and 
need for regulated voltage make them ideal for placement 
with a Tiny Track, MICE or PICE kits. All 3 can provide 
the current required to drives the LVC receivers. The 18 
LVC and 18-5 Hzare the only receivers in the family to 
give you | PPS outputs. This is not critical for APRS but 
needs to be looked at if you want a timing solution. For 
more differences on the LVC receivers, please visit www. 
garmin.com/manuals/425_TechnicalSpecification.pdf. 

I did some playing with and actual APRS use with 
the 18PC. First thing that I found was my Kenwood 
D700 and D7AG) were happy with the 18PC. I did not 
have to alter any settings on the receiver. The 18PC does 
have the ability to output the newer 2.3 version of NEMA 
0183 but I did not test the compatibility since version 2.0 


works just fine. I moved onto connecting the 18PC toa 
Kantronics KPC3 (not a plus version). You do have to use a 
null modem if you connect to the DB25 of the Kantronics 
TNGs, but that is normal. Using the same configuration I 
used with my Garmin GPSMap’6, the tracker took off like 
a charm. I test with WinAPRS, APRS+ and ULView with the 
same performance results I see with my I+ and GPSMap 
16. 


I found that acquisition times were very close to 
the times given in the documentation. If] left the receiver 
off overnight, it would take typically 10 seconds to find 
itself. Ifleft off over a week, a little over a minute was typical. 
Again, similar to my GPSMap76 but better than my I+. 
All the receivers in the GPS 18 family make use of WAAS 
corrections. If you wish to turn it off, you just download the 
software from Garmin and make whatever changes you 
need, This includes enabling the 2.3 version of the NEMA 


protocol. 


Overall I am happy with the Garmin 18PC. It does not 
get more plug and play than this. Ifyou are going to move 
your receiver between applications on occasion, the 18PC is 
the way to go. The built in magnet will keep the receiver on 
your roof at highway speeds. The low profile is a big bonus. 
If you are looking for a receiver and do not require a display, 
I would recommend the Garmin GPS18. 


HE 
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Eliminating Source Routing from APRS, Part 3 


By Pete Loveall, AE5PL, pete@ae5pl.net 


The NSR (NoSourceRouting) algorithm appears to 
have stabilized with input from a number of people 
over the past six months. Suggestions incorporated 
into the algorithm were verified to adhere to the NSR 
concept of no userdefined paths. Suggestions not 
incorporated usually tried to provide “limited” source 
routing. As has been shown, any introduction of 
source routing into the algorithm opens the network 
to breakage and therefore the NSR algorithm would 
bring no benefit to the amateur community if those 
suggestions were implemented. 


First, here is the algorithm as shown at www.aprs- 
is.net: 


1. The digipeater repeats any packets it sees from 
a station on its “must digipeat” list. This allows 
specific remote stations to make it into the “metro” 
LAN as deemed proper by the digipeater sysop. The 
digipeater will modify the path by simply appending 
its call with the H-bit set after the “ok” list digipeater 
call plus any path defined by the sysop. 


2. The digipeater repeats everything it sees directly 
(no digipeated packets), stripping the entire path away 
and replacing it with just the digipeater’s callsign with 
the H-bit set plus any path defined by the sysop. 


3. The digipeater repeats any packets it sees last 
digipeated by a digipeater on its “ok” list unless it 
sees that it has been digipeated by a digipeater on 


its “exclude” list. This allows remote areas to make 

it into the “metro” LAN as deemed proper by the 
digipeater sysop. The digipeater will modify the path 
by simply appending its call with the H-bit set after 
the “ok” list digipeater call plus any path defined by 
the sysop. 


RELAY can be on the “ok” list allowing people 
to set up low-level RELAY alias digipeaters. Packets 
with RELAY in the path would only be digipeated if 
RELAY is in the first position and no place else. 


The digipeater does full dupe checking (CRC 
or checksum) based on from call, unproto (not 
including the SSIS), I field length, and I field data. 
The digipeater will not digipeat any packet where its 
callsign appears before or including the call with the 
H-bit set in the path. The depth of this dupe check 
would only need to be about 30 packets long. 


It is important to note that the only part of the 
algorithm that is directly related to APRS is the 
dupe check algorithm (accounting for the sparsely 
implemented SSID routing on the unproto 
destination field). The NSR algorithm is a digipeater 
implementation for the AX.25 UI protocol. APRS 
also makes use of the AX.25 UI protocol and this is 
why APRS has been referenced in the title. 


Why do we need a new digipeater algorithm for the 
AX.25 UI protocol? Because the current digipeater 


mechanism is broken and has been proven over the 
years to simply not work for communications of more 
than one or two hops. It is interesting to note that 
the authors of the AX.25 protocol foresaw this (from 
the APRS 2.0 specification) “It is anticipated that 
multiple-repeater operation is a temporary method 
of interconnecting stations over large distances until 
such time that a layer 3 protocol is in use. Once 

this layer 3 protocol becomes operational, repeater 
chaining should be phased out.” The current AX.25 
specification (2.1) restricts digipeating to two hops. 
Yet many in the APRS world are against stabilizing 
the network by mandatory digipeater reductions. 
Why? Let’s take a look at their reasons and how the 
NSR algorithm actually provides better network 
performance and stability. 


1. “Only the user knows where their packets 
should go.” 


This is a holdover from 30 years of failed 
networking attempts by the amateur community. 
When AX.25 was introduced, amateurs immediately 
tried to use the digipeater fields to allow the user to 
define their own paths. This required the individual 
user to know the network topology which most 
did not. It also attempted to use a very bandwidth 
restricted RF channel for multiple repeats of the same 
packet. This caused excessive collisions and relatively 
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unusable, isolated networks. Even so, all the “fixes” 
relied on various methods of digipeating on the 
same bandwidth restricted channel which eventually 
caused their failure. 


2. “The problems with digipeaters in the past were 
because those were using a connected protocol.” 


The problems seen in the past are being seen today 
on the unconnected APRS network. The type of 
protocol doesn’t obfuscate the fact that multiple 
repeats of packets on a bandwidth restricted channel 
increases collisions and decreases network reliability 


and usability. 


3. “This is amateur radio and I don’t want my 
packets to go via non-RF means.” 


Amateur radio has been using non-RF backbones 
since the 1950’s (at least). This doesn’t make the 
RF network any less amateur radio. And, it doesn’t 
make communicating between RF networks any less 
amateur radio, especially if you do not know how 
your communication is being routed. 


The NSR algorithm accounts for the fact that the 
primary RF channel is bandwidth restricted and 
being competed for by multiple stations. As such, it 
looks at each area defined by the digipeater sysops 
as a local area network (LAN). As with any LAN 
network design, interconnection of the LAN’s is 
done using a separate wide area network (WAN), 
not by trying to adapt multiple, disparate LAN’s to 


adhere to a common communications medium. 
Why a separate WAN? To eliminate or reduce 
collisions on the LAN thereby increasing the usability 
and performance of each individual LAN. 


In the APRS world, gateways have been developed 
which provide filtered connectivity between the 
LAN’s. This connectivity is primarily, but not 
exclusively, via the Internet. The need for the 
“filtered” connectivity is because there is over 10 
times the bandwidth used on the WAN backbone 
than is available on the individual LAN’s. 


4. “We need to change our routing in an 
emergency.” 


The only group that might want to change their 
routing (and the only group that should control such 
routing changes) is the group at the center of the 
emergency. This should be done by that emergency 
group coordinating with the digipeater sysop, not 
by trying to change radio configurations of all the 
users during the actual emergency. This is simply 
common sense and known to all those trained 
in emergency communications: KISS “Don’t try 
changing configurations across multiple devices 
during an emergency.” The NSR algorithm allows 
for the minimum number of devices to be changed 
to achieve an altered network topology so the 
participants can concentrate on the emergency, not 
configuring their radios. 
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5. “I want to check into a net in a different LAN.” 


This is done without configuration changes 
by simply messaging the net control. The NSR 
digipeaters and the gateways take care of _all_ the 
routing issues. 


So where does this leave the NSR algorithm? It 
leaves it as the only solution today, which guarantees 
amore stable, usable network than that which 
is currently implemented. Digipeater authors 
worldwide are implementing it. We hope that 
Kantronics and IW3FQG recognize the value and 
simplicity of the algorithm and implement it in their 
respective digipeater ROM’s. 


As stated above, the NSR algorithm is an AX.25 UI 
digipeater implementation, not an APRS digipeater 
implementation. It was a mistake for a non-link 
level protocol to try and dictate how the linklevel 
protocol should behave. With the advent of the 
APRS gateway, layer 3 routing is available essentially 
available to APRS. The NSR algorithm makes the 
link-level protocol a true layer 2 protocol with no 
veiled attempts at making it a partial layer 3 protocol. 
With the modifications to the algorithm made over 
the last six months, the NSR algorithm can be put 
in place within the current network architecture and 
immediately start bringing benefits to the APRS 
community. 


HHH 
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T238+ - A Second Generation Weather Station 


By Will Beals, NOXGA, will@beals5.com 


The original T238 design has gone through two 
production runs. Rather than a third identical 
run, the team requested the design be optimized 
more for its target use, and the T238+ was born. 


The T238s main electronics consisted of 
a micro, an LCD panel, RS232 drivers, and 
support electronics for the 1-Wire® interface 
and switches. The support electronics included 
all the needed circuitry for code development 
as well. The T238 takes the raw data from the 
various supported weather sensors, converts the 
raw data to meaningful measurements and send 
the weather data in APRS® or Peet® format to a 
TNC for transmission. 


The T238+ started with the original design, 
removed the explicit debug support (more on this 
later), two of the three serial port headers, and 
added a daughter card that is capable of driving 
a radio directly instead of relying on a TNC. The 
size of the main board layout was reduced to the 
same size as the LCD module to make assemblies 
much easier. There will still be only one code 
base for the T238 and T238+; release will operate 
on either platform. 


While the explicit debugger support was 
removed from the T238+, code development is 


still possible. By cutting two traces and installing 
a debug header and different frequency crystal 
oscillator, the full code development features of 
the T238 can be restored. 


The MX-614-based modem board operates 
much like other small standalone APRS devices. 
It does not operate as a full-function TNC, 
but rather allows the T238+ to send data if the 
channel is clear. Circuitry for receive is included 
and while it is “just a matter of software” to 
enable receive features, it is not envisioned at this 
time. 


The two main challenges with the T238+ were 
the compact board designs and the modem 
software support. Noise susceptibility was one of 
the weaker points of the T238, so in addition to 
reducing the are of the T238 to less than half it’s 
original size, I wanted as close to a full ground 
plane as possible on the solder side of the board. 
Further complicating things were no flexibility 
in pin choices to keep backward-compatibility 
with the T238. The ground plane remained solid 
except for nine traces that needed to be routed 
on the ground plane. An additional eight short 
lines were purposely routed on the bottom to 
facilitate cutting for debug modes and potential 


swizzling of the 1-Wire connector signals. The 
free CIRCAD98 for Windows tools proved to be 
a great toolset for schematics, layout, and rules 
checking between the two. Through both sets of 
board spins, there were no errors due to layout 
problems. I highly recommend these tools. Lots 
of help from TAPR in general and John Koster in 
particular also helped! 


Software development for the T238+ was the 
other big challenge. The challenge came from 
an unexpected place however. The single biggest 
problem was finding sufficient documentation on 
how to format an APRS packet for transmission. 
The AX.25 specification is fairly complete save 
one critical area, how to generate the Frame 
Check Sequence or FCS, a form of CRC. The 
AX.25 specification referred only to an ISO 
3309 specification that was not publicly available 
and had also been superseded by another 
specification. Other public domain references to 
algorithms called out in that specification were 
for different size CRCs. I spent weeks trying 
to search for information before giving up and 
resorting to a more direct approach—I analyzed 
someone else’s APRS source code and copied it! I 
hasten to add it was with the author’s permission 
after he also admitted he was not able to follow 
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any published specifications and got his code 
working by trial and error. 


Since getting the code working, I have reverse 
engineered the algorithm to the point where 
I was able to regenerate the FCS calculating 
it a byte at a time instead of a bit at a time; 
something not possible unless you really 
understand the algorithm. I have written up 
all these experiences in an article intended 
for a DCC where I explain the entire process 
from starting with an ASCII message (an APRS 
packet), adding headers, footers, calculating the 
FCS, bit stuffing, and finally tone generated as a 
result. My intention is this will be a fairly stand- 
alone explanation requiring very little external 
references to understand the complete process. 
The paper is mostly written save some sorely 


needed flow diagrams for the FCS. 


My prototype T238+ weather station has been 
on the air for almost six months now and TAPR 
has just started selling the kids after an extended 
beta test run. A critical requirement for the 
station is that it be extremely reliable as several of 
them are located at very remote sites. Save some 


lockups on the early code, most of the early issues 


appear to have been related to external hardware 
issues. 
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W1FB Technical Excellence Award 


Three radio amateurs were honored as recipients of the 2004 Doug DeMaw, W1FB, Technical 
Excellence Award. Created to honor the late Doug DeMaw, W1FB~one of the most widely published 
technical authors in Amateur Radio history-the award is bestowed upon the author or authors of the 
best QST or QEX technical article during the prior year, as judged by the ARRL Technical Advisor 
group. DeMaw was the ARRL Technical Department Manager and Senior Technical Editor from 1970 
to 1983. 


For the best of 2004, the voting ended in a tie between the collaboration of Tom McDermott, N5EG, 
and Karl Ireland for their article “A Low-Cost 100 MHz Vector Network Analyzer with USB Interface,” 
in July/August QEX, and Jack Belrose, VE2CV, for his article “On the Quest for an Ideal Antenna 
Tuner,” in October QST. Accordingly, the ARRL bestowed the Technical Excellence Award on both 


articles and their authors. 


An ARRL Life Member, McDermott has been licensed for 35 years. He’s a member of the IEEE 
and holds a bachelor’s in electrical engineering. His Amateur Radio interests lie in HF digital 
communications, hardware and software design, and an occasional HF contest. As part of the Texas 
Packet Radio Society, he designed the hardware and some of the protocols for the TexNet packet 
switching network, and has been involved in numerous TAPR projects. He has written a textbook on 
wireless communications, and holds eight patents. McDermott currently serves as chief technical officer 


at Chiaro Networks. 


Ireland graduated from Ohio Institute of Technology and has worked as a broadcast engineer for 
KNUS, KVIL and WBEN. He designed high-speed VCXOs and receivers for fiber optics systems at 
Alcatel/Rockwell International, earning three patents in phase-locked loops and lockand-acquisition 
circuits. Ireland is currently employed at Austin Instrument Systems, where he works on satellite systems. 


The DeMaw Award consists of an engraved nine-inch pewter cup. 
From ARRLWeb, www.arrLorg 
HHH 
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Using NOS Software as a Possible Solution 
By Maiko Langelaar, VE4KLM, http://www.langelaar.net 


With the recent surge (it seems) of packet radio 
telnet nodes for use in emergency and welfare 
communications, one solution has perhaps not got 
the attention it deserves — NOS (Network Operating 
System), also known as JNOS, MFNOS, TNOS, 
WAMPES, and other derivatives of the original 
KA9Q Network Operating System (NOS). Despite the 
fact that it has been around for more than 15 years, 
and labeled obsolete by many, it is still a decent 
solution for those seeking an alternative to the 
Windows based systems out there, since NOS runs 
in both DOS and Linux environments. For purposes 
of this article, all of the NOS variants will be treated 
the same, since fundamentally they are all capable 
of serving as telnet nodes and e-mail portals for that 
matter. 


NOS goes back to the DOS days, and is a single 
monolithic application that had it’s own IP stack, 
complete with services like email, ftp, dns, http, 
pop, smtp, and others. It allowed DOS users to have 
a complete TCP/IP system on a pathetic little 386, 
and share it with the rest of the IP network. You 
ran a DOS packet driver (TSR) for your network 
card, and then ran NOS on top of that. Your NOS 
on DOS (no pun intended) box served your LAN 
with all the services you needed. Then the variants 


appeared, allowing people with packet radio 
equipment to access these same services over RF. 
Further more, the NOS systems allowed the packet 
radio user to interface with systems on the network 
side, in essence providing a network gateway service, 
now more commonly known as an internet gateway. 
Years later, some of the NOS variants were ported to 
the Linux environment. 


From a systems integrator point of view, I see 
NOS as a flexible solution - integrating the world 
of packet and HF digital radio with the internet 
(or with just a local LAN for that matter), and vice 
versa. 


It’s important to note that NOS is a standalone 
system, and does not need an IP network to 
function. It’s perfectly fine on it’s own, without the 
Internet or a LAN to connect to. But it serves well 
as an Internet gateway if that is what one is looking 
for. 


If you want to provide emergency email or telnet 
services for packet radio users in your area, please 
consider looking at NOS as a possible solution for 
your needs. Just google “JNOS 2.0” or “MFNOS” 
or “TNOS” or “WAMPES.” 


The JNOS 2.0 variant is maintained by myself, 


and is based on the JNOS 1.11 distribution last 
maintained by James Dugal, NSKNX. I hope this 
article peaks your curiosity or at least renews an 
old interest you may have once had with the NOS 
software. 


HHH 
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BWRIE 


By John Blowsky, KB2SCS, kb2scs@optonline.net 


Back in 2001, I created a system that I called Both Way 
Radio Internet Email (BWRIE, for short). This system 
makes it possible for the user to send and receive Internet 
email. 

I have just updated BWRIE, so you no longer have to 
install Pegasus Mail. The older version of BWRIE used 
Pegasus Mail as its POP3 client. Now BWRIE has its own 
built in POP3 client. 


BWRIE is freeware. There is no charge to use BWRIE. 
You can find BWRIE at www.gsl.net/kb2scs. 
Why Was BWRIE Created? 


I created BWRIE to fill the perceived need of being able 
to receive and send Internet emails from inside a disaster 
area. I did not design BWRIE to be run on a daily basis. 
Rather, its strength lies in the fact that it is a dedicated 
system, i.e., a system designed to do one thing and to do 
that one thing very well. As a result, BWRIE is very easy to 
setup and has a very small learning curve. 

BWRIE consists of two plain vanilla AX25 packet radio 
stations. One named “Receive” and the other named 
“Send.” 

The Receive station consists of: 

1) PC capable of running Windows 98 or better 

2) TNC 

3) Transceiver 


4) Internet connection (fulltime or dialup, either will 
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work) 
5) BWRIE software that I named Receive. 


Another name for the Receive station would be 
“Internet Gateway.” 


The Send station consists of: 

1) PC capable of running Windows 98 or better 
2) TNC 

3) Transceiver 

4) BWRIE software that I named Send. 


Let us say that a hurricane has devastated Suffolk 
County, Long Island, NY. Let also say that this hurricane 
did very little damage to Connecticut. The Town of 
Islip (NY) EOC has given you the task of sending and 
receiving Internet email in and out of stricken Suffolk 
County. 


Since BWRIE is come as you are, you simply take your 
laptop and your AX.25 packet radio station to the Islip 
EOC. Note: using BWRIE does not require a connection 
to the Islip EOC local area network. Once your station is 
set up, you find a repeater in Connecticut, and transmit 
a CQ. Since the hams in Connecticut know about the 
disaster in Suffolk County, finding someone willing to 
help should not be a problem. 


Since Connecticut has little damage from the 
hurricane, the Internet in Connecticut is working fine. 
The ham that you contact in Connecticut from the 
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comfort of his/her own home, downloads BWRIE and 
installs it on his/her PC. BWRIE has a very easy setup 
program so the installation of BWRIE is a snap. 


BWRIE also has an integrated Windows Help system; 
so learning how to use BWRIE is not a problem. The 
ham in Connecticut only has to run Receive, so he/she 
only has to learn about Receive. There is no need for 
interaction between Receive and a host of other programs. 


Through the repeater, the ham in Connecticut tells 
you the call sign and SSID that he/she will be using with 
BWRIE. You agree on a VHF or UHF band and a packet 


frequency to use. 


That is all there is to it. After establishing a connection 
via RF between the Islip EOC and the Connecticut 
station, Internet e-mail will be able to go in and out of 
stricken Suffolk County. For the ham in Connecticut, 
BWRIE from this point is automatic. The ham in 
stricken Suffolk County is the one who causes all the RF 
transmissions from the Receive station in Connecticut. 
This means no worries about a non-ham causing a 
transmitter to key up. 

The From addresses of the e-mail that Receive sends out 
to the Internet are formatted with the sender’s first and 
last name and the e-mail address of the Receive station. 

For example, the Receive station in Connecticut has the 
following e-mail address: Super@myisp.com. The Send 
station sends an email to Receive that is from John Doe. 
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The From email address that Receive will send out would 
be John Doe (Super@myisp.com). At the end of the e 
mail, Receive adds the following lines: 


“This message was sent via Amateur Radio. If you 
would like to learn more about Amateur Radio then 
please check out the following URL: www.arrlorg 


“Tf you would like to send a reply to this message. 
Then please click on the ‘REPLY’ button on your email 
program. Note: Your Reply will be sent via Amateur 
Radio. No attachments. No HTML. No business 
communications. No foul language. Also please no long 
quotes of original message. Except for the quotes the 
above are rules of the FCC. Please adhere to these rules. 
The Amateur Radio operators License is at stake.” 


The reply email would go to Super@myis.com. This 
works out well since that is the email address of our 
Receive station. Send will see a listing of the Internet e-mails 
that Receive receives. This above reply email will be one of 
them. The operator of Send can request this email from 
Receive and Receive will send this email via packet radio to 
Send. 


If you would like a more detailed description of 
BWRIE, then please go to www.tapr.org and find my 
paper that is in the 2001 DCC proceedings. The title of 
the paper is “BWRIE.’ 


Hn 


- Santa Ana, California is hosting 
the premier venue for digital 

= anthuslasts of every skill lavel 
At the conference you'll learn about 
the latest advances In digital 
“communications and share ideas 
with the best and brightest of the 
Amateur Radio community. 

In addition to the conference, you 
can also Indulge yourself and your 
family In local attractions such as 
Disneyland, Disney California 
Adventure, Knott's Berry Farm and 
the gorgeous California beaches. 


Santa Ana, California 1 


Call Tucson Amateur Packet Radio (TAPR) today at 972-671-8277, or register on-line at www.tapt.org/dec/ tf $ 
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TAPR is a community that provides leadership and resources to 
radio amateurs for the purpose of advancing the radio art. 
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